REMARKS 

Claims 1-6 are pending in the present application. Claims 1-6 have been amended 
herewith. Reconsideration of the claims is respectfully requested. 

Applicants would initially like to thank the Examiner for taking the time to 
conduct a telephonic interview with Applicants' representative on December 14, 2004. 
While no agreement was reached, Applicants representative emphasized the 
authentication forwarding technique which mitigates client account requirements on 
multiple servers. 

I. 35 U.S.C. § 103, Obviousness 

The Examiner rejected Claims 1-6 under 35 U.S.C. § 103 as being unpatentable 
over U.S. Patent Number 6,052,681 issued to Richard Harvey (Harvey) in view of U.S. 
Patent Number 6,598,057 issued to Eric Synnestvedt (Synnestvedt) . This rejection is 
respectfully traversed. 

Generally speaking, the present invention is directed to a technique for 
authenticating directory referral searches, sometimes referred to as LDAP referral 
searches. LDAP provides a referral model which allows client computers to ask an 
LDAP server a question and be told to contact another server - thus the concept of 
'referral'. The LDAP clients are responsible for contacting these other referred to or 
referenced servers. One of the major problems associated with the referral mechanism is 
that the user needs to bind to the other referral/reference servers, with different 
distinguished names (DNs) existing on these reference servers. Without such binding, 
the referred search to the reference server would be an unauthentic ated request. The 
present invention provides a technique for access to such referral/reference servers 
without requiring a physical user account to reside on each referral/reference server, and 
in particular provides a technique for authenticating referral searches. The ability to 
authenticate referral searches advantageously provides this ability to access 
referral/reference servers without requiring a physical user account to reside on each 
referral/reference server. 
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With respect to Claim 1 (and dependent Claim 2), such claim recites steps of (i) 
receiving a bind request from a referred search request; (ii) searching a local directory of 
a server for an entry corresponding to the distinguished name (DN) of the bind request; 
(iii) authenticating the bind request if an entry for the bind DN is located within the local 
directory; (iv) checking a defined reference server for the prefix of the bind DN, if the 
bind DN is not found within the local directory; (v) contacting the reference server for 
authentication, if the prefix of the bind DN is located on the reference server; and (vi) 
denying the bind request if both the local directory and the reference server do not 
contain an entry corresponding to the bind DN. In rejecting Claim 1, the Examiner states 
that Harvey teaches the recited receiving (step (i)) and searching (step (ii)) steps at 
Harvey column 32, line 53 - column 33, line 48. Applicants show that there, Harvey 
states: 



5.5 Search Service 

The Search Service is the most complex of all X.500 services. Search 
arguments indicate where to start the search (baseObject), the scope of the 
search (subset), the conditions to apply (filter) and what information 
should be returned (selection). In addition, a flag is passed to indicate 
whether aliases should be dereferenced (searchAliases). 

The possible values for subset are baseObject, oneLevel and 
wholeSubtree. Base object indicates that the search filter will only be 
applied to attributes and values within the base object. OneLevel indicates 
the Search filter will be applied to the immediate subordinates of the base 
object. Whole subtree indicates the Search filter will be applied to the base 
object and all of its subordinates. 

A simple example of a filter condition would be: surname- 'EVANS" or 
telephoneNumber PRESENT. 



X.500 definition 



Argument Description 



baseObject The Distinguished Name of the baseObject 
subset baseObject, oneLevel or wholeSubtree 
filter search conditions 

searchAliases a flag to indicate whether aliases among 
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subordinates of the base object should be 

dereferenced during the search. 

selection EIS as for READ. The attributes and values to 

be returned. 

Common Arguments 



Result Description 



DistinguishedName The DN of the selected object (returned if an 

alias is dereferenced) 
entries Attributes & values (as defined in selection) for 
the entries which satisfy the filter. 

partialOutcomeQualifier An indication that an incomplete result was 

returned, eg, a time limit or size limit 
restriction. 
Common Results 



The search procedures for each search scope are outlined as follows: 
Base Object 

Perform a tree walk using the DIT table, resolving aliases if necessary. 
Obtain the EID of the base object. 

Apply the filter to attributes and values in the Search Table with the EID 
of the selected object. 

If the filter condition is matched, return the Entry Information from the 
Entry Table. 

If an alias is dereferenced, return the DN using the Tree Table to extract 
the PATH and the Name Table to build the DN. 
One Level 

Perform a tree walk using the DIT table, resolving aliases if necessary. 
Obtain the EID of the base object. 

Check to see if any aliases exist with PARENT=EID and if so resolve 

them to obtain an aliases dereferenced list. 

Using the Search and DIT Tables, apply the filter (attribute/value 

conditions) and the scope (PARENT=EID of selected object and any 

aliases dereferenced). A list of matching EID ! s will be returned. 

If an alias is dereferenced, return the DN using the Tree Table to extract 

the PATH and the Name Table to build the DN. 

For each matching EID: 

Return the Entry Information obtained from the Search Table using the 
Entry Table (as per Read Service). 
Whole Subtree 

Perform a tree walk using the DIT table, resolving aliases if necessary. 
Obtain the EID of the base object. 
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Check to see if any aliases exist with PATH prefix matching the PATH of 
the selected object. 

For each alias discovered, check to see if the alias points outside the 
current subtree and if it does repeat the previous step. Once all aliases 
have been resolved, a set of unique base objects will have been found 
(with no overlapping areas). 

Using the Search and Tree Tables, apply the filter (attribute/value 
• conditions) and the scope (PATH LIKE PATH prefix of the selected 
object) to each unique base object. A list of matching EID's will be 
returned. 

If an alias is dereferenced during Navigation (not during searching), return 
the DN using the Tree Table to extract the PATH and the Name Table to 
build the DN. 

As can be seen, this passage discusses a general X.500 Search Service. Such search 
service includes search arguments that indicate where to start the search, the scope of the 
search, the conditions to apply, and what information should be returned (column 32, 
lines 55-57). In addition, a flag is passed to indicate whether aliases should be 
dereferenced (column 32, lines 58-59). In contrast, Claim 1 expressly recites a step of 
"receiving a bind request from a referred search request" (emphasis added). The cited 
passage does not teach or suggest any type of bind request from a referred search 
request. To establish prima facie obviousness of a claimed invention, all of the claim 
limitations must be taught or suggested by the prior art. MPEP 2143.03. See also, In re 
Royka, 490 F.2d 580 (C.C.P.A. 1974). As all claim limitations are not taught or 
suggested by the cited references, as shown above, a prima facie case of obviousness has 
not been established with respect to Claim 1. 

Further with respect to Claim 1, Applicants urge that none of the cited references 
teach or suggest the claimed step of "searching the local directory for an entry 
corresponding to the distinguished name (DN) of the bind request". As the cited 
reference does not teach a bind request from a referred search request, there similar is no 
teaching of a distinguished name (DN) of such missing bind request from a referred 
search request, and thus there is no teaching or suggestion of searching a local directory 
for an entry corresponding to a (missing) distinguished name (DN) of a (missing) bind 
request from a referred search request. Rather, the cited Harvey reference teaches that a 
distinguished name is received as an input parameter of a Search Service request (the 
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basedObject, as shown in the X.500 definition table in column 33, lines 8-9). The 
requested search service is not associated with any type of bind request from a referred 
search request, as expressly recited in Claim 1 . Therefore, it is further shown that a 
prima facie case of obviousness has not been established with respect to Claim 1 . 

Still further with respect to Claim 1, none of the cited references teach or suggest 
a claimed step of conditionally authenticating a bind request. Per Claim 1, the bind 
request is authenticated if an entry for the bind DN is located within a local directory of 
the server. In rejecting Claim 1, the Examiner states that this step is taught by 
Synnestvedt at column 6, lines 1-11. Applicants show that there, Synnestvedt states: 

Inputs to the Match and Generate Processes 

Inputs to the generation process include a boolean flag indicating the DOCSIS 
configuration file is being generated on behalf of the TFTP server 124. If the file is being 
generated for the TFTP server 124, then the generation request will be authenticated and 
LDAP directory lookups for certain objects will be restricted to the snapshot cache taken 
at server start-up. Otherwise, the authentication is skipped, the LDAP cache is not pre- 
populated, and directory lookups may read from the LDAP directory if the object is not 
found in the cache. 

As can be seen, this cited passage describes a conditional authentication of a generation 
request. The 'condition' for which authentication is performed is whether a configuration 
file is being generated on behalf of a TFTO server. This is different from Claim 1 for at 
least two reasons. First, the cited reference teaches authentication of a generation 
request, whereas Claim 1 is with respect to authenticating a bind request from a referred 
search request. Second, the cited reference teaches that the conditional authentication is 
based upon whether a configuration file is being generated on behalf of a TFTO server, 
whereas Claim 1 's conditional authentication is based upon whether an entry for a bind 
DN is located within a local directory. Thus, is it shown that the cited Synnestvedt 
reference does not teach or suggest the claimed conditional authentication step recited in 
Claim 1 . Therefore, it is further shown that a prima facie case of obviousness has not 
been established with respect to Claim 1. 
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Still further with respect to Claim 1, such claim recites "checking a defined 
reference server for the prefix of the bind DN, if the bind DN is not found within local 
directory", and "contacting the reference server for authentication, if the prefix of the 
bind DN is located on the reference server". If the bind DN is not found within the local 
directory, a reference server is checked for the prefix of the bind DN and if this prefix is 
located on the reference server, the reference server is contacted for authentication. 
These claimed steps provide an ability to authenticate referral searches, and in particular 
advantageously provides an ability to access reference servers without requiring a 
physical user account to reside on each reference server. In rejecting Claim 1, the 
Examiner states that Harvey teaches checking a defined reference server for the prefix of 
the bind DN if it is not found within the local directory at column 33, lines 54-64. 
Applicants show that this passage merely states that a determination is made as to 
whether an alias points outside of the current tree. There is no discussion of any bind 
DN, prefix of a bind DN, or a reference server. Thus, this passage does not teach or 
otherwise suggest the claimed step of "checking a defined reference server for the prefix 
of the bind DN, if the bind DN is not found within the local directory". The Examiner 
states that the claimed step of contacting the reference server is also taught at this same 
Harvey passage. In addition to the reasons just listed (and in particular the fact that there 
is no concept of a reference server per these teachings), this passage merely teaches 
checking of a PATH prefix to return a list of matching EID's for base objects. There is 
no teaching or suggestion of any type conditional contact with a reference server (in 
particular, there is no teaching/suggestion of contacting the reference server if the prefix 
of the bind DN is located on the reference server). Because there is no 
teaching/suggestion of conditional contact with a reference server, it similarly follows 
that there is no teaching/suggestion of conditional contact with a reference server for 
authentication. Nor has the Examiner alleged any conditional contact with a reference 
server for authentication. Therefore, it is further shown that a prima facie case of 
obviousness has not been established with respect to Claim 1. Applicants have amended 
Claim 1 to further clarify this distinction and to further highlight advantages and features 
of the present invention that are not taught by the cited references - and in particular the 
advantageous authentication forwarding capability where a server contacts a reference 
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server for authentication. This claimed feature advantageously provides the ability to 
access referral/reference servers without requiring a physical user account to reside on 
each referral/reference server. 

Still further with respect to Claim 1, such claim recites "denying the bind request 
if both the local directory and the reference server do not contain an entry corresponding 
to the bind DN" As can be seen, the denial of the bind request is based upon two 
conditions being met - (i) the local directory and (ii) the reference server not containing 
an entry corresponding to the bind DN. In rejecting Claim 1, the Examiner cites 
Synnestvedt column 8, lines 18-24 as teaching such claimed step. Applicants show that 
there, Synnestvedt states: 

Validate the source IP address of the TFTP request by comparing the 
source address of the TFTP request to the IP address of the cable modem 
obtained from the IP address lease object. If the addresses do not match, 
then the configuration file is not generated, an informational message is 
logged, and a status is returned indicating the request could not be 
authenticated. 

As can be seen, this passage states that a status is returned indicating a request could not 
be authenticated if a source address of the TFTP request does not match the cable modem 
IP address. This is different from the claimed 'denying' step recited in Claim 1 for at 
least two reasons. First, the request for which authentication is denied is a TFTP request 
from a cable modem (column 7, lines 65-66; see also column 1, lines 10-19 where the 
TFTP protocol is described to be a file transfer protocol that can only read and write files 
from and to a remote server), whereas per Claim 1 a bind request is denied. Second, the 
'denial' as taught by the cited reference is merely based upon whether two addresses 
match, whereas Claim 1 recites that the denial of the bind request is based upon two 
conditions being met - (i) the local directory and (ii) the reference server do not 
containing an entry corresponding to the bind DN. Therefore, it is further shown that a 
prima facie case of obviousness has not been established with respect to Claim 1. 

Further with respect to dependent Claim 2, Applicants urge that none of the cited 
references teach or suggest the claimed feature of "wherein the defined reference server 
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contains root DN's; and server location". In rejecting Claim 2, the Examiner states that 
this is taught by Harvey at column 9, lines 1-28. Applicants show that there, Harvey 
states: 



X.500 defines its objects to be hierarchical. The relationships between objects 
follow a tree structure where each object has a parent object and each parent can 
have zero or more children. This relationship can be represented in a general 
PROPERTY table by the addition of a "parent name" column, which is used to 
store the name of the parent object (see Table 1 .3b). 

TABLE 1.3b 



X.500 Property Table 
object name parent name type syntax value 



Datacraft root Organization String Datacraft 
Datacraft root Address Postal PO Box 353 

Address Croydon VIC 
Chris Masters Datacraft Name String Chris 
Chris Masters Datacraft Surname String MASTERS 
Chris Masters Datacraft Title String Sales Manager 
Chris Masters Datacraft Phone Numeric 03 727-9456 
Chris Masters Datacraft Mobile Numeric 018 042671 
Alana Morgan Datacraft Name String Alana 
Alana Morgan Datacraft Surname String MORGAN 
Alana Morgan Datacraft Title String Sales Support 
Alana Morgan Datacraft Phone Numeric 03 727-9455 



Note that the root of the tree has no parent. Thus, if both Chris and Alana work 
for Datacraft and Datacraft is a child of the root then we can say that Chris and 
Alana are children of Datacraft and that Datacraft is the parent of Chris and 
Alana. 

This passage describes a property table showing various hierarchical relationships 
between objects. This is different from what is recited in Claim 2 for at least two 
reasons. First, this table has nothing to do with a defined reference server. Per Claim 2 
(which depends upon Claim 1), the defined reference server is something that gets 
checked if a bind DN is not found within a local directory. The cited passage does not 
teach such a defined reference server, and thus doesn't teach or suggest a defined 
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reference server that contains root DN's and server location. Second, the cited passage 
does not teach any type of server location, as expressly recited in Claim 2. Therefore, it 
is further shown that a prima facie case of obviousness has not been established with 
respect to Claim 2. 

With respect to Claims 3 (and dependent Claim 4) and 5 (and dependent Claim 6), 
Applicants traverse for similar reasons to those given above with respect to Claim 1. 

Further with respect to dependent Claims 4 and 6, Applicants traverse for similar 
reasons to the further reasons given above with respect to dependent Claim 2. 

Therefore, the rejection of Claims 1-6 under 35 U.S.C. § 103 has been overcome. 

II. Conclusion 

It is respectfully urged that the subject application is patentable over the cited 
references and is now in condition for allowance. The Examiner is invited to call the 
undersigned at the below-listed telephone number if in the opinion of the Examiner such 
a telephone conference would expedite or aid the prosecution and examination of this 
application. 



date: [za^^/ay 



Respectfully submitted, 




Reg. No. 34,2895 
Wayne P. Bailey 
Reg. No. 34,289 



Yee & Associates, P.C. 



P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 



Attorneys for Applicants 
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